Half-Duplex Virtual Routing and Forwarding (HDVRF) maintain separate routing policy information entries to forward network traffic through a network node depending on the direction of the network traffic. Maintaining separate routing policy information (e.g., half duplex VRF information) for different directional traffic ensures that such traffic can be forwarded through a specified node and eventually to a target even though the network traffic may have otherwise traversed a shorter, more direct path to reach the target. A detailed description of HDVRF can be found in co-pending patent application Ser. No. 10/674,079, having the same inventorship and Assignee as the present application. The contents of patent application Ser. No. 10/674,079 are herein incorporated by reference in their entirety.
One conventional implementation of HDVRF involves maintaining separate upstream routing policy information and downstream policy information at a first network node supporting throughput of network traffic. The upstream routing policy information at the first node is used to identify a second node to forward upstream traffic (e.g., network traffic received from one or multiple sources traveling in a first direction) received from a first client communicating through the first node. The downstream routing policy information at the first node is used to forward downstream network traffic (e.g., network traffic received from one or multiple sources traveling in a second direction) received from another node to the first client. Thus, in general, separate routing policy entries are maintained to support routing and forwarding of traffic depending on their direction. By preventing use of the downstream policy routing information to route upstream network traffic, the first node may forward or route traffic along a path that the network traffic otherwise would have not traveled. Thus, network traffic communicated through the first node can be forced to travel through a network node (e.g., a second node) that it would have not otherwise have traveled if the downstream policy information was used to route the network traffic.
It should be noted that use of the relative terms upstream and downstream merely identify network traffic in different directions. For example, in the context of a service provider network supporting transmission of messages between a client and a service provider network, upstream traffic may be network messages received from a client for transmission to a target device such as a provider edge ‘hub’ node or customer edge ‘hub’ node. Downstream traffic may be network traffic received at the first node from a wholesale service provider network (or at least traffic routed through the service provider network).
In another conventional implementation of HDVRF, the first network node may be configured to receive a session initiation request from a client desiring to establish a session to communicate through the first node. The client may not yet be assigned a network address for transmitting and receiving data messages. Upon receipt of the session initiation request, the first node may obtain network address assignment information from a network address server (e.g., a RADIUS server that assigns IP addresses for use by requesting clients) for the first client that generated the session initiation request. The assignment information including network address information may be forwarded to the first node and other network nodes for creating routes. For example, an assigned network address may uniquely identify a client over other nodes in the network.
In addition to notifying the client of its assigned network address information, the first node may populate its downstream routing policy information to include the network address information identifying the requesting client node. Generally, inclusion of the network address information of the client in the downstream routing policy information enables the first node to route information received from other upstream nodes back to the client. In one application, the first node populates the downstream policy information (e.g., VRF information for routing data packets to the clients) with network address information of each new client associated with a given service. Thus, a list of supported clients nodes may be dynamically updated depending on establishment and termination of client network sessions.
Because the upstream and downstream routing policy information varies depending on which direction of traffic they support, they each may include information associated with multiple clients. For example, the downstream routing policy information may be a VRF including a list of multiple clients supported by or coupled to the first node. In contradistinction, conventional methods require tracking separate VRF instances for each of multiple clients. According to an embodiment of HDVRF, one VRF for upstream information includes a default address (or aggregate) or target (e.g., a hub) to route the upstream traffic while another VRF for the downstream traffic includes a list of multiple client's network address information. Based on the reduction of the number of separate VRF instances, overhead maintenance of VRFs and use of memory resources to store the VRFs is reduced.
After the downstream policy information is populated in the first node for a new client, the first node may distribute the network address information populated in the downstream policy information (at the first node) to other nodes via use of a notification message distributed according to a system routing protocol such as BGP (Border Gateway Protocol). For example, the first node may be a first provider edge node of a network to which multiple clients are coupled. The first provider edge node may distribute each new network address associated with corresponding clients to a second node such as a second provider edge node of a core network supporting MPLS. Generally, the network address information sent to the second node (or multiple relevant nodes in a wholesale service provider network) is used to update routing policy information at the second node. The routing policy information at the second node is used in turn to identify a route on which to forward appropriately destined traffic to the clients coupled to the first provider edge node.
As discussed, for traffic received from the clients (such as upstream traffic), the first node utilizes the upstream routing policy information to identify a target node to forward the traffic regardless of a destination address associated with the traffic. More specifically, the first node may receive a network message from a client coupled to communicate through the first node. The first node utilizes the upstream routing policy information in the first node to identify a path or default route on which to forward the network traffic. Even if a destination address of the network traffic is another client coupled to the first node, the first node looks up a target route in the upstream routing policy information to identify a default route or node (such as a provider edge hub node or customer edge hub node) to forward the traffic. This technique of preventing use of the downstream routing policy information at the first node forces the network traffic to travel a path that it otherwise may not have traveled if the downstream routing policy information were available (e.g., in the same VRF table) to route upstream traffic. For example, if a first client coupled to the first node sends a message to a second client coupled to the first node, the first node might route the message received from the first client directly to the second client if the downstream routing policy information were available to route data. According to principles of the present invention, the message is forwarded along a route or target (such as a default route or target) specified by the upstream routing policy information even though a shorter path may exist directly back to the second client.
According to one conventional implementation, the upstream routing policy information and downstream policy information at the first node enables establishment of a VPN (Virtual Private Network) connection between the first node and the second node (e.g., the default hub node) on which to forward traffic from the first client. Based on routing policy information at the second node, a return path (such as another VPN) may be established between the second node and the first node on which to forward the network messages to the first client through the first node.
Forcing traffic to travel through a node that it otherwise would not have traveled serves multiple purposes. For example, a target-specific packet processing technique for monitoring data packet flows may be implemented at the second node (such as a node of an ISP network) to monitor an amount of traffic associated with a particular client. Thus, a service provider may identify how much to charge a client for transmitting data through the network. Additionally, a monitoring authority such as an agency may monitor contents of data packets at the second node to identify whether the network is being used for illicit purposes.